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Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

Sir: 

We, Dan Alan Brendes, Joseph William Keller, and Seetharaman Khadri, being 
the inventors of the subject matter of the claims in the above-referenced U.S. patent 
application, declare as follows: 

1. Prior to March 31, 2000, we produced a working feature in the United States, 
referred to as the MTP Primitives Feature, that performed the steps claimed in 
the above-referenced patent application of detecting a network management 
event regarding the status of an SS7 node residing in the SS7 network, in 
response to detecting the network management event, generating a data network 
management message indicating the operating status of the SS7 node, and 
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sending the data network management message to nodes in the data network 
that are adapted to communicate with the SS7 network. 

2. As evidence that a working version of the MTP Primitives Feature existed prior to 
March 31, 2000, we attach Exhibits A and B, which will now be explained in 
detail. 

3. Exhibit A is a document entitled IP7 Secure Gateway 2.0 MTP Primitives 
Software Unit Test Plan (hereinafter, "MTP Primitives Testing Document"), which 
describes testing of the MTP Primitives Feature. The MTP Primitives Testing 
Document was created in October of 1999 and describes testing of the MTP 
Primitives Feature that occurred in October and November of 1 999. 

4. In Section 1.1, the MTP Primitives Testing Document indicates that its purpose is 
to verify the correct operation of the MTP Primitives Feature of the IP7 Secure 
Gateway 2.0. The MTP Primitives Feature is the same MTP Primitives Feature 
referred to our in original Declaration under 37 C.F.R. § 1.131 filed in the U.S. 
Patent and Trademark Office on April 7, 2005 (hereinafter, "original Rule 131 
Declaration"). The IP7 Secure Gateway 2.0 includes an Eagle® STP platform 
with SS7 over IP signaling capabilities. 

5. In Section 2 of the MTP Primitives Testing Document, Table 2 indicates that the 
Test Plan for the MTP Primitives Feature covers compliance with the Feature 
Description. 

6. The Feature Description referred to in the MTP Primitives Testing Document is 
the same MTP Primitives Feature Description referred in our original Rule 131 
Declaration. 
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7. In Section 5 of the MTP Primitives Testing Document, line 1 of Table 14 indicates 
that 34 of the 48 Feature Description (FD) compliance tests were completed and 
the pass rate was 100%. 

8. In Section 5.2.1 of the MTP Primitives Testing Document, Table 15 indicates by 
number the FD compliance tests that were completed and the completion dates. 
Test numbers FD2-FD14 for which data is not completed in the Table 15 were 
assigned to Seetharaman Khadri. 

9. Exhibit B is a status report from Seetharaman Khadri for the week of 1 1/08/1999- 
11/12/1999 indicates that 36 of the 37 tests assigned to him were completed 
successfully. 

10. The tests that were completed include tests, such as FD2, FD5, and FD7 
referenced in the MTP Primitives Testing Document, that tested the capability of 
the MTP Primitives Feature to detect a network management event regarding the 
status of an SS7 node residing in the SS7 network, in response to detecting the 
network management event, generate a data network management message 
indicating the operating status of the SS7 node, and send the data network 
management message to nodes in the data network that are adapted to 
communicate with the SS7 network.. 

11. The development and testing of the MTP Primitives Feature were completed at 
Tekelec's offices in Morrisville, North Carolina. 

We hereby declare that all statements herein of our own knowledge are true and 
that all statements made on information and belief are believed to be true; and further 
that these statements were made with the knowledge that willful false statements and 
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the like so made ard punishable by fine or imprisonment, or both, under §1001 of Title 
18 of the United States Code and that such willful false statements may jeopardize the 
validity of the applicaftion or any patent issued thereon. 



Dan Alan Brendes Date 



Joseph William Keller! ' Qatg 



Seetharaman Khadri Date 



Enclosure: 

Exhibit A: m Secure Gateway 2.0 MTP Primitives 
Exhibit B: Sjtatus Report for week of 11/08/1999-11/12/1999 
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the like so made are punishable by fine or imprisonment, or both, under §1 001 of Title 
18 of the United States Code and that such willful false statements may jeopardize the 
validity of the application or any patent issued thereon. 
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1. INTRODUCTION 

1.1 Purpose 

This document specifies the testing that is necessary to verify the correct operation of the MTP Primitives feature of IP7 Secure 
Gateway 2.0. This feature provides status of point codes in the SS7 network to IP connected network elements through the 
MTP primitives. These primitives function similar to the MTP3 network management procedures for TFA, TFP, TCA, TCP, 
TFC and UPU. 

1.2 Scope 

This document is intended for engineering and the design verification test group. The reader is expected to be familiar with the 
IP7 Secure Gateway, the TALON test tool, MTP3 network management procedures and the MTP Primitives Detail Design as 
documented in [5]. 

1.3 References 

[1] TEKELEC Acronym Guide, 070203M0.MWD, Revision 1.14, Tekelec, August 1996. 

f4][21/P^ Secure Gateway 2.0 Product Functional Specification, pfD02525.doc, Revision 1 .5, J. Mason, Sept. 1999. 
\S ] \3]IP7 Secure Gateway 2.0 MTP Primitives, fd002782.doc, Revision 1.1, Tekelec, October 1999. 
\^[^Transport Adapter Layer Interface 2.0, tr002733.doc, Revision 1 .5, Tekelec, October 1999. 
P^\5V P7 Secure Gateway 2.0 MTP Primitives, dd002910.doc, Revision 1.0, Tekelec, October 1999. 
i^MFekelec Implementation of TALI, tp002892.doc. Revision 1.0, Xu, October 1999. 

1.4 Acronyms 

In addition to the acronyms defined in [1], the acronyms below are used in the document. 



Acronym 


Definition 


IP-NE 


Internet Protocol Network Element 


IP-SCP 


Internet Protocol Switching Control Point 


MGC 


Media Gateway Controller 


MTP? 


MTP Primitive 


RCT 


signalling-route-set-congestion-test 


SG 


Secure Gateway 


TALI 


Transport Adoption Layer Interface 


TFA 


Transfer Allowed 


TFP, 


Transfer Prohibited 


TCA 


Transfer Cluster Allowed 


TCP 


Cluster Prohibited 


TFC 


Transfer Controlled 


UPU 


User Part Unavailable 



Table 1: List of Acronyms 
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2. TESTING STRATEGY 

The IP-FE will be simulated using the TALON test tool. TALON is expected to support the TALI 2.0 protocol and provide 
user interfaces to generate TALI packets that will test all aspects of the MTP Primitives feature. This feature mainly impacted 
the SS7IPGW GPL. However, since common files did change, all affected GPLs will be made with the common files and run 
during execution of this test plan. 

The test cases should address the following areas. If an area is not applicable please put N/A in the area's section: 

> FD Compliance Testing — Any testing that is related to a Feature Description. Particular attention is given to the 
requirements and objectives of the FD 

> Specification Compliance Testing—Any testing that is related to an external specification. Particular attention is given to 
the requirements and objectives of the compliance document. 

> Design Testing —Any testing that is related to a TEKELEC Design Specification 

> Line of Code Testing — Any testing that ensures all code paths are executed, particularly default cases and error cases. 

> Performance Testing — Any testing that is yields quantifiable results. 

> Command Scripts — Any test that tests EAGLE commands 

> Load/StressA^ olume - - Any testing that is designed to isolate and stress a particular subsystem. 

> PR Testing— Any testing related to a FD referenced problem report 

> Fault Insertion Testing — Any testing that purposely inserts faults into the test 

> Sanity Testing --Typically would be a set of standard test cases. No unique test cases would appear here. 

> Regression Testing —Typically would be a set of standard test cases that focus on the area affected by change 

> Upgrade Testing - Specific upgrade testing is necessary if the FD includes upgrade impact. 





Covered in Test Plan 


Not Covered in Test Plan 


FD Compliance Testing 






Specification Compliance Testing 




V 


Design Testing 


V 




Line of Code Testing 






Performance Testing 






Command Scripts 




V 


Load/StressA^ olume 






PR Testing 




V 


Fault Insertion Testing 






Sanity Testing 


V 




Regression Testing 






Upgrade Testing * 




V 



Table 2: Test Coverage 

* Not always required (see text above for Upgrade Testing for explanation) 
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2.1 Test SETUP(S) 



2.2 Eagle Station Setups 

The following figure depicts a sample configuration for an EAGLE station that could be used by this test plan. The following 
figure shows a sample network configuration where the shaded box represents Eagle 201.01 which is connected to Eagle 
201 .06. Using this configuration, multiple traffic patterns can be run. For example, ISUP traffic can be generated from a 
MGTS shelf routed to TALON via one of the SS7IPGW cards. TALON can flip the OPC/DPC and send the message back to 
the originator. Another possible configuration involves the MGTS generating traffic that is routed to the other Eagle which 
perform global title translation on the traffic sending the MSU back to the originating Eagle. The originating Eagle could then 
global title the traffic to the originating MGTS link. 





Figure 1: Eagle 201.01 
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SYSDATA Command File 


n Aeagles w\script\20 1 0 1 .cmd 


MOTS Account 


mgtsl02 


MGTS Location 


203.02.06 


203.03.05 


203.02.04 




MGTS Configuration - Standard 


mgst2030206 default 


mgst2030305_default 


mgts2030204 itudef 




MGTS Configuration - Working 


mgst2030206_work 


mgst2030305_work 


mgts2030204_ituwork 





EAGLE Cards: 



Location 


Type 


Application 


Location 


Type 


Application 


Location 


Type 


Application 


1101 


TSM 


SCCP 


1201 


DCM 


IPLIM 


1211 


ILA 


SS7ANSI 


1102 


TSM 


SCCP 


1202 






1212 


ILA 


SS7ANSI 


1103 


DCM 


IPLIM 


1203 


ILA 


SS7ANSI 


1213 


ILA 


SS7ANSI 


1104 






1204 


ILA 


SS7ANSI 


1214 


ILA 


SS7ANSI 


1105 


DCM 


SS71PGW 


1205 


ILA 


SS7ANSI 


1215 


ILA 


SS7ANSI 


1106 






1206 


ILA 


SS7ANSI 


1216 


ILA 


CCS71TU 


1107 


DCM 


SS71PGW 


1207 


ILA 


SS7ANSI 


1217 


HCAP 


ATMANSl 


1108 






1208 


ILA 


SS7ANSI 


1218 


HCAP 


ATMANSI 


1111 


ACM 


SLAN 




1112 


ASM 


GLS 



2.3 Traffic Mixes 

2.3.1 Traffic IVlix #1 : MGTS Generates SCCP Traffic 

The 1 1-1-x mgts ssps attached to 2-11-0 are used to generate seep ttaffic that gets global titled at both eagles and returns to the 
originating mgts ssp where sequence verification and msg loss detection can occur. The 'michael_xu_group' of udms is used. 
The 'michael_xu_group' is defined w/ UDM #1 = ip7_sccpudt_l l_l_35jo_2_16_l, UDM #2 = 
ip7_sccpudt_l l_l_45_to_2_16_l ' and so on thru udm #8 (11_1_105) and udm #9 (1 1_1_25). 

• Traffic originates from 1 1-1-35 thru 1 1-1-105 destined for 2-16-1. 

• The traffic is through switched at 20101 over either Isn e2e3 or Isl 105 or Isl 107. 

• Traffic arrives at 20106 and goes to its seep card. Global title database converts the new dpc to 2-1 1-1. 

• Traffic is routed back to 20101 over either Isn e3e2 or Isl 105 or Isl 107. 

• Traffic arrives at 20101 and goes to its seep card. Globabl title database converts the new dpc to 1 1-1-35 to 1 1-1-105 
based on the originator. 

• Traffic is through switched at 20101 over to the correct ss7 card and back to the originating mgts. 

The UDMs #10-#18 can be used to send the same basic traffic in the opposite direction (from 16-1-x to 2-11-1 and back again). 

4.4^2.3.2 Traffic Mix #2: MGTS Generates NPLT Traffic 

The % MSU, MSU Minimum Size and MSU Maximum Size slide bars in the MOTS NPLT screen are used to configure traffic 
of the desired type to go across the 201.01 and 201.06 Eagle stations. 

• The SSPs on the opposite side of each other in the network map send to each other (ie: 1 1-1-10 to/from 16-1-10, 1 1-1-x 
to/from 16-1-x) 

• The default Service type to use for this traffic will be SI = 2 (Network Test/Maintenance Messages, special) 

• appl rtkeys for all of these point codes, with si=2, will need to be added to the 20101 and 20106 stations. 

2.3.3 Traffic Mix #3: MGTS Generates ISUP Traffic 

The MGTS SSPs attached to an EAGLE are used to generate ISUP traffic destined to a Talon station having a virtual point 
code. A MGTS message group, such as 'jac_pr27568,' is used which has several UDMs defined. Each UDM is an ISUP 
message destined to a specific point codes (typically a Talon virtual point code). 

• traffic originates from an MGTS node destined to a Talon station having virtual point code. 

• traffic is through switched at the EAGLE over Isn e2e3 and Isl 105. 

• traffic arrives at the Talon station and Talon replies to the originator. 

• reply traffic is through switched at the EAGLE over to the correct ss7 card and back to the originating MGTS node. 
The UDMs are 42 bytes in size. 
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2.4 Setup Scripts 

In addition to the Eagle configuration scripts listed in the preceding tables, a number of additional scripts shall be used during 
testing. The following table lists the names and capabilities of the various scripts. All scripts are located in n:\keller\scripts. 



Script Name 


riirpose 01 dcripi 


zU 1 U 1 \ent49soc .cmd 


Configures additional 49 sockets on each SS7IPGW card (for connection to the 
ouier eagiej. J\ii socKeis arc useu lo carry some uaiiit-. ijCdvc inc ny new bucKcib 

in tVif* 'nrrvVi ' ctntf* 
ill liiC' piuii aiaic 


^ W 1 \J\J NCIlltr/SUCClHU 


^amf* a<; aHfivp Hut fnr 901 Ofi 




Allows thp 40 npw <;nrlcpts 


701 0/i\nlw40 cnr rmH 


^amp a<; ahnvp Hut fnr 901 06 


901 01 VrirnJ-Ocnr rmH 


PmViiHitc tHp 40 npw QnrVptQ 


901 OA\r*rnJ.Ocrkr rmH 


^nmp pnr»vp hut \C\x 901 On 


901 01 \Hlt4Qcnr rmH 


r^plptpc tlip cnrVptc tViat wprp mnfioiirpH in *pnt40QnrV 


901 0^^\Hlt4Qcnr rmH 


^5imp pnnvp hilt \C\t 901 On 


90 101 \pr»tir»lrt rmH 


Pntpr rniitPQ tn rmitp traffir frnm 1 0 A/ffrXS nnHp^ nvpr thp TPT TlVf link 


901 0^^\pr>tir\lrt rmH 


Qiimp ahr*\7P hilt fr»r 901 C\f\ 


20101\dltiplrt.cmd 


Delete routes that route traffic from 10 MGTS nodes over the IPLIM link. 


20106\dltiplrt,cmd 


Same as above but for 20106. 


20101\dltipgrt.cmd 


Delete routes that route traffic from 10 MGTS nodes over the IPGW link. 


20106\dltipgrt.cmd 


Same as above but for 20106. 


20003\ent50ss.cmd 


Provision 50 server sockets for dcmpeerl 105a and dcmpeerl 107a. 


20003\ent50cs.cmd 


Provision 50 client sockets for dcmpeerl 105a and dcmpeerl 107a. 


20003\dlt50soc.cmd 


Delete 50 sockets for dcmpeerl 105a and dcmpeerl 107a. 


20003\alw50soc.cmd 


Open and allow 50 cli ;nt sockets for dcmpeerl 105a and dcmpeerl 107a. 


20003\inh50soc.cmd 


Close and inhibit 50 client sockets for dcmpeerl 105a and dcmpeerl 107a. 


20003\entlOkey.cmd 


Provision 1 0 route keys to route ISUP traffic from MGTS nodes to Talon point 
code 5-5-5 over Is 1 105. Each route key is associated with rive sockets. Provision 
10 route keys to route IbUr traiiic irom Mul o nodes to pomt code o-o-o over 

Id 107 P^rVi rniitp Vpv i^ n^QnrintpH witli fivp ^nrVpt^ 

lo 1 IV//. lwjd\..<ll iV/ULv lo dooU^idl&U Willi 11 oV/^^viS. 


20003\dhl0key.cmd 


Delete 10 route keys that route ISUP traffic from MGTS nodes to Talon point code 
5-5-5 over Isl 105. Delete 10 route keys that route ISUP traffic from MGTS nodes 
to point code 6-6-6 over Isl 107. Each route key is associated with five sockets. 


20003\ent50cli.talon 


Configure 50 Talon clients to connect to Eagle 200.03, 1 105. 


20003\dlt50cli.talon 


Kill 50 Talon clients that connect to Eagle 200.03, 1 105. 


20003\ent50srv.talon 


Configure 50 Talon servers to receive connections from Eagle 200.03, 1 105. 


20003\dlt50srv.talon 


Kill 50 Talon servers that receive connections from Eagle 200.03, 1 105. 


20003\reply50.talon 


Configure 50 Talon clients to reply to ISUP messages. 


20003\reply50s.talon 


Configure 50 Talon servers to reply to ISUP messages. 



Table 3: Scripts 



2.5 Hardware Requirements 

There are no special hardware requirements for testing this feature other than those documented in the Eagle setup. 

2.6 MGTS Configuration 

The MGTS configuration is documented in the Eagle setup. 

2.7 How to Techniques 

SORP settings can be determined using the SOCKSTATE PASS command. Additionally, the MSUCOUNT PASS command 
can be used to monitor MTP Primitive transmit, receive and discard counts. For example, every time this document mentions 
"verify the primitive is discarded", the MSUCOUNT command can be used to verify the count has incremented by one. 
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3. 



MATRIX COMPLIANCE AND TEST COVERAGE KEY 



Key 


Meaning 


FC 


Fully Compliant 


PC 


Partially Compliant 


NC 


Not Compliant 


FT 


Fully Tested 


FT 


Partially Tested 


NT 


Not Tested 



3.1 Requirements Matrix 



Table 4: Test Coverage Key 



Requirement 
ID 


Requirement Description 


Compliance and 
Comments 

(FC, PC, NC) 


Test Coverage 
and Comments 

(FT, PT, NT) 


Test Case 


FD-1 


The sending of Primitives shall be configurable on a socket 
basis via inband registration. 


FC 


FT 


FD-2 


FD-2 


The Secure Gateway shall provide an indication to all IP 
devices, via a point code/cluster unavailable message, when 

a nnint rndp has bpromp iinrpachahlp 


FC 


FT 


FD-8. FD- 10 


FD-3 


The Secure Gateway shall send a point code/cluster 
unavailable to an IP device in response to a point code 
status message if the specified point code/cluster is 
unavailable. The indication will be sent back to the 
reniiestor via the same <inrket which the reaiiest was 
received. 


FC 


FT 


FD-35, FD-36, 
FD-37,FD-38, 
FD-39, FD-40, 
FD-42, FD-44, 
FD-45 


FD-4 


The Secure Gateway shall send a point code/cluster 
unavailable to an IP device in response to a service message 
if the Hestination nnint rode/cluster is unavailable The 
indication will be sent back to the requestor via the same 
socket which the service message was received. 


FC 


FT 


FD-28 through 
FD-32 


FD-5 


The Secure Gateway shall provide an indication to all IP 
devices, via a point code available/cluster message, when a 
point code/cluster has become available 


FC 


FT 


FD-7, FD-9 


FD-6 


The Secure Gateway shall send a point code/cluster 
available to an IP device in response to a point code/cluster 
status message, if the specified point code/cluster is 
available. The indication will be sent back to the requestor 
via the same socket which the request was received. 


FC 


FT 


FD-33,FD-34, 
FD-41,FD-43, 
FD-46, FD-47, 
FD-48 


FD-7 


For TFCs destined for an IP node, the Secure Gateway shall 
send congestion level indication to all IP devices that match 
the destination point code from the TFC. The congestion 
level in the TFC will be used for the congestion level in the 
indication. 


FC 


FT 


FD-ll,FD-27 


FD-8 


MTPP audit primitives shall be discarded if the total 
number of messages in the three queues mentioned in the 
section 3.7 of [3] is above the max_bfr_cnt value of 
congestion threshold table. 


FC 


FT 


FD-1 8 


FD-9 


Point code/cluster availability/unavailabihty or congestion 
level primitives shall be ignored if received by the 
SS7IPGW card. 


FC 


FT 


FD-20 through 
FD-25 
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Requirement 
ID 


Requirement Description 


Compliance and 
Comments 

(FC, PC, NC) 


Test Coverage 
and Comments 

(FT, PT, NT) 


Test Case 


FD-10 


The Concerned Point Code parameter of all MTP Primitives 
received shall be validated as a valid point code. The 
validation consists of verifying byte 3, which indicates the 
type of point code, conforms to the definition provided by 
Table 10 of [3], Otherwise, the primitive will be discarded. 


FC 


FT 


FD-15 


FD-11 


The Source Point Code parameter of the Request for 
Congestion Status Primitive (CONG AUD) shall be 
validated as a valid point code. The validation consists of 
verifying byte 3, which indicates the type of point code, 
conforms to the definition provided by Table 10 of [3]. 
Otherwise, the primitive will be discarded. 


FC 


FT 


FD-16 


FD-12 


The congestion level parameter in the CONG AUD 
primitive shall be validated as a valid congestion level The 
validation consists of verifying the level conforms to the 
definition provided by Table 19 of [3]. Otherwise, the 
primitive will be discarded. 


FC 


FT 


FD-17 


FD-13 


The Primitive Operation field of each received primitive 
will be validated as a valid operation value. The validation 
consists of verifying the value conforms to the definition 
provided by Table 19 of [3]. Otherwise, the primitive will 
be discarded. 


FC 


FT 


FD-19 


FD-14 


Each non-discarded congestion request primitive shall 
generate a RCT MSU with the DPC, OPC and network 
priority based on the data in the congestion request 
primitive. 


FC 


FT 


FD-3 through 
FD-6 


FD-15 


Each application sockets will default to disable broadcast 
phase and response method primitive transmissions and 
return to default state when the socket closes. The IP 
device is responsible for re-enabling the primitives. 


FC 


FT 


FD-i,FD-2 


FD-16 


Each transmitted primitive shall be counted as one unit of 
work with respect to the transmit capacity. 


FC 


FT 


FD-12 


FD-17 


Each received primitive shall be counted as one unit of 
work with respect to the receive capacity. 


FC 


NT - Rx capacity 
testing done in [6] 


NA 


FD-18 


The MSUCOUNT PASS command shall be modified to 
display measurements on a per link basis related the 
number of primitives transmitted, received and discarded. 


FC 


FT 


FD-3, FD-7, 
FD-20 


FD-19 


The SOCKSTATE PASS command shall be modified to 
display the version of TALI the far end is using and which 
MTP Primitives are enabled. 


FC. 


PT-TALI version 
testing is 
performed in [6] 


FD-2 


FD-20 


The TALI layer shall provide on a per-sockci basis a string 
indicating what version of the TALI interface that the SG is 
capable of communicating. This version is also referred as 
the "near end" capable version. 


FC 


NT -TALI 
version testing is 
performed in [6] 


NA 


FD-21 


The TALI layer shall provide on a per-socket basis a string 
indicating what version of the TALI interface that the IP 
node is capable of communicating. This version is also 
referred as the "far end" capable version. 


FC 


NT -TALI 
version testing is 
performed in [6] 


NA 


FD-22 


The TALI layer shall provide on a per-socket basis a string 
indicating as to what version of the TALI interface has been 
negotiated between the SG (near end) and IP node (far end). 


FC 


NT -TALI 
version testing is 
performed in [6] 


NA 


DD-1 


SORP must maintain counts of sockets with MTP 
Primitives enabled 


FC 


FT 


FD-2 
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Requirement 
ID 


RcQuiremcnt Description 


Comments 

(FC, PC, NC) 


Toe*' /^/\»/<»i*a 
I csl V'UVcl agv 

and Comments 

(FT, PT, NT) 




DD-2 


Connection loss processing must decrement SORP socket 
counts if necessary 


FC 


FT 


FD-2 


DD-3 


No broadcast phase messages shall be put on MTP work 
queue unless at least one socket has broadcast phase MTP 
Primitives enabled. 


FC 


FT 


DT-8 


DD-4 


No response method messages requiring replication shall be 
put on MTP work queue unless at least one socket has 
response method MTP Primitives enabled. 


FC 


FT 


DT-9 


DD-5 


Audits will be discarded if socket has closed since the 
request was generated. 


FC 


FT 


FD-13,FD-14 



Table 5: Test Compliance Matrix 



4. TEST CASES 

4.1 Test Numbering Rules 

The following numbering scheme shall be used for unit test case numbers. 

XX-(Y)-N 

> XX is the prefix for the test group/category using the table below. 

> Y is optional and is to be used when there are subcategories of tests within a category (i.e., various categories of tests with 
the Detailed Design section) 

> N is a sequential numbering scheme used within each category. 



Test Category 


Prefix 


FD Compliance Testing 


FD 


Specification Compliance Testing 


SC 


Design Testing 


DD 


Line of Code Testing 


LC 


Performance Testing 


PT 


Sanity Testing 


ST 


Regression Testing 


RT 


Command Scripts 


CS 


Load/StressA^ olume 


LS 


PR Testing 


PR 


Fault Insertion Testing 


FI 


Upgrade Testing 


UG 



EXAMPLES 
FD-l,FD-2, FD-3 
DD-1-01, DD-1-02 



Title: IP7 Secure Gateway 2.0 MTP Primitives 

Doc No.: tp002911.docTP0Q29-14-.dQC | Revision #: 1.2 
Page 12 of 27^7 



4t24.2 FD Compliance Testing 

This section focuses on the MTP Primitive feature's support for the FD requirements identified in [3]. 



Test# 


Command/Scenario 


Response/Result 


FD-1 


Test that all MTPP and SORP variables are initialized 
properly. This includes using the SOCKSTATE and 
MSUCOUNT PASS commands. 


Verify SOCKSTATE reports SORP MTP 
Primitives are disabled. Verify 
MSUCOUNT reports no primitives 
transmitted, received or discarded. Verify 
the MTP state is IDLE. Verify the SORP 
counts are 0. 


FD-2 


Verify SORP flags are treated independently and counts 
are maintained correctly. 

1 . With no other sockets up, bring up 1 socket 

2. Send SORP with broadcast phase only ON 

3 . Send SORP with broadcast phase OFF 

4. Send SORP with response method ON 

5. Send SORP with response method OFF 

6. Send SORP with both ON 

.7. Send SORP with broadcast phase only OFF 

8. Send SORP with response method OFF 

9. Send SORP with both ON 

10. Send SORP with both ON 

1 1 . Close socket 


1 . Verify SORP flags for socket is 0 and 
MTP counts are 0. 

2. Verify only broadcast bit is set, 
broadcast count is 1 and response count 
is 0. 

3. Verify SORP flags for socket is 0 and 
MTP counts are 0. 

4. Verify only response bit is set, response 
count is 1 and broadcast count is 0. 

5. Verify SORP flags for socket is 0 and 
MTP counts are 0. 

6. Verify both broadcast and response bits 
are set and both response and broadcast 
coimts are 1 . 

7. Verify only response bit is set, response 
count is 1 and broadcast count is 0. 

8. Verify SORP flags for socket is 0 and 
MTP counts are 0. 

9. Verify both broadcast and response bits 
are set and both response and broadcast 
counts are 1 . 

1 0. Verify both broadcast and response bits 
are set and both response and broadcast 
counts are 1 . 

1 1 . Verify SORP flags for socket is 0 and 
MTP counts are 0. 


FD-3 


Send two identical request for congestion status primitives 
with the only difference being the congestion level within 
0.5 seconds. 


Verify that only the first primitive is 
converted to a RCT and sent to MTP3. 
Verify the MTP Primitive receive count is 
incremented by 2. 


FD-4 


Send request for congestion status when the congestion 
audit history table is empty. 


Verify that a properly formatted RCT is sent 
to MTP3. 


FD-5 


Send request for congestion status when the congestion 
audit history table is full without a match to the requested 
concerned point code. All of the table's entries should not 
"age" out. 


Verify that a properly formatted RCT is sent 
to MTP3. 


FD-6 


Send request for congestion status when the congestion 
audit history table is full without a match to the requested 
concerned point code. At least one of the table's entries 
should "age" out. 


Verify that a properly formatted RCT is sent 
to MTP3. 
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Test# 


Command/Scenario 


Response/Result 


FD-7 


Generate broadcast TFA message with sockets configured 
as following: 

1 ) at least 2 sockets with MTP Primitives disabled 

2) at least 2 sockets with broadcast phase only enabled 

3) at least 2 sockets with response method only enabled 

4) at least 2 sockets with all MTP Primitives enabled 


Verify the point code available primitive is 
only transmitted on sockets with broadcast 
phase enabled. Verify using MSUCOUNT 
that the MTP Primitive transmit coimt is 
incremented appropriately. 


FD-8 


Generate broadcast TFP message with sockets configiu-ed 
as following: 

1) at least 2 sockets with MTP Primitives disabled 

2) at least 2 sockets with broadcast phase only enabled 

3) at least 2 sockets with response method only enabled 

4) at least 2 sockets with all MTP Primitives enabled 


Verify the point code unavailable primitive is 
only transmitted on sockets with broadcast 
phase enabled. 


FD-9 


Generate broadcast TCA message with sockets configured 
as following: 

1 ) at least 2 sockets with MTP Primitives disabled 

2) at least 2 sockets with broadcast phase only enabled 

3) at least 2 sockets with response method only enabled 

4) at least 2 sockets with all MTP Primitives enabled 


Verify the cluster available primitive is only 
transmitted on sockets with broadcast phase 
enabled. 


FD-10 


Generate broadcast TCP message with sockets configured 
as following: 

1) at least 2 sockets with MTP Primitives disabled 

2) at least 2 sockets with broadcast phase only enabled 

3) at least 2 sockets with response method only enabled 

4) at least 2 sockets with all MTP Primitives enabled 


Verify the cluster unavailable primitive is 
only transmitted on sockets with broadcast 
phase enabled. 


FD-11 


Send various TFC messages to a socket that has response 
method primitives enabled. 


Verify all valid fields (i.e. source point code 
and congestion level) can be generated. 


FD-12 


Test IPGW transmit scheduler sequencing between MSUs, 
MTP Primitives and SORP Primitives occurs as expected: 

1) all MSUs 

2) all MTP Primitives 

3) combination MSUs, MTP Primitives and SORP 
Primitives 


Verify transmit capacity is used for each 
transmitted PDU. 

1) 100% MSUs 

2) 100% MTP Primitives 

3) approximately 60% MSUs, 30% MTP 
Primitives and 10% SORP Primitives 


FD-13 


Drop socket connection after sending point code audit to 
SG. 


Verify primitive is discarded. 


FD-14 


Drop and reestablish socket connection after sending point 
code audit to SG. 


Verify primitive is discarded. 


FD-15 


Send every type of MTP Primitive with the following 
values for the control byte of the concemed point code: 

1) 0 = ANSI full point code 

2) 1 = ITU International full point code 

3) 2- ITU National ftill point code 

4) 3 = unused 

5) 4 = ANSI cluster point code 

6) 5 = invalid 

7) 255 = invalid 


Verify primitives for options 4, 6 and 7 are 
discarded and for all other options the 
primitive is processed. 
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Test# 


Command/Scenario 


Response/Result 


FD-16 


Send request for congestion status primitive with the 
following values for the control byte of the source point 
code: 

1 ) 0 = ANSI full point code 

2) 1 = ITU International full point code 

3) 2 = ITU National full point code 

4) 3 = unused 

5) 4 = ANSI cluster point code 

6) 5 = invalid 

7) 255 - invalid 


Verify primitives for options 4, 6 and 7 are 
discarded and for all other options the 
primitive is processed. 


FD-17 


Send request for congestion status primitive with the 
following values for congestion level: 

1 ) 0 = congestion level 0 

2) 1 = congestion level 1 

3) 2 = congestion level 2 

4) 3 = congestion level 3 

5) 4 = unused 


Verify primitives for option 5 is discarded 
and for all other options the primitive is 
processed. 


FD-18 


Send excessive point code audit primitives from TALON 
where excessive is enough audits to exceed the maximum 
buffer count threshold defined by HMCG. 


Verify excessive audits are discarded. 


FD-19 


Send MTP Primitive with invalid operation field. 


Verify primitive is discarded. 


FD-20 


Send point code available primitive to SG. 


Verify primitive is discarded. 


FD-21 


Send point code unavailable primitive to SG. 


Verify primitive is discarded. 


FD-22 


Send cluster available primitive to SG. 


Verify primitive is discarded. 


FD-23 


Send cluster unavailable primitive to SG. 


Verify primitive is discarded. 


FD-24 


Send user part unavailable primitive to SG. 


Verify primitive is discarded. 


FD-25 


Send congestion destination with congestion level 
primitive to SG. 


Verify primitive is discarded. 


FD-26 


Send SORP Primitive with invalid operation field. 


Verify primitive is discarded. 


FD-27 


Send TFC with invalid congestion level destined for IP 
node. 


Verify congestion destination with 
congestion level primitive is generated with 
invalid congestion level. 


FD-28 


Send from TALON a MSU with the concerned point code 
set to the SG's capability point code, the SI set to 3 and 
SCCP unequipped. 


Verify point code unavailable primitive is 
transmitted to TALON on same socket MSU 
was received on. 


FD-29 


Send from TALON a MSU with the concerned point code 
set to the SG's capability point code and the SI set to 8. 


Verify point code imavailable primitive is 
transmitted to TALON on same socket MSU 
was received on. 


FD-30 


Send from TALON a MSU with the concerned point code 
that has no route in the routing table. 


Verify point code imavailable primitive is 
transmitted to TALON on same socket MSU 
was received on. 


FD-31 


Send from TALON a MSU with the concerned point code 
whose route in the routing table is inaccessible. 


Verify point code unavailable primitive is 
transmitted to TALON on same socket MSU 
was received on. 


FD-32 


Send from TALON a MSU with the concerned point code 
set to the SG's capability point code, the SI set to 3, no 
SCCP service and MSU requires global title. 


Verify point code imavailable primitive is 
transmitted to TALON on same socket MSU 
was received on. 


FD-33 


Send from TALON a point code audit primitive where the 
concerned point code is the SG's true point code. 


Verify a point code available primitive is 
transmitted on the same socket the audit was 
received. 


FD-34 


Send from TALON a point code audit primitive where the 
concerned point code is the SG's capability point code and 
SCCP service is allowed. 


Verify a point code available primitive is 
transmitted on the same socket the audit was 
received. 
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Test# 


Command/Scenario 


Response/Result 


FD-35 


Send from TALON a point code audit primitive where the 
concerned point code is the SG's capability point code and 
SCCP service is not allowed. 


Verify a point code unavailable primitive is 
transmitted on the same socket the audit was 
received. 


FD-36 


Send from TALON a point code audit primitive where the 
concerned point code is an ANSI point code which doesn't 
have a route in the routing table and the cluster is 
unknown. A cluster is unknown if there is no provisioned 
cluster entry for the route key and there is no full point 
code or true/capability point code entry that matches the 
cluster. 


Verify a cluster unavailable primitive is 
transmitted on the same socket the audit was 
received. 


FD-37 


Send from TALON a point code audit primitive where the 
concerned point code is an ANSI point code that doesn't 
have a route in the routing table and the cluster is known. 
A cluster is known if there is a provisioned cluster entry 
for the route key or there is a full point code or 
true/capability point code entry that matches the cluster. 


Verify a point code unavailable primitive is 
transmitted on the same socket the audit was 
received. 


FD-38 


Send from TALON a point code audit primitive where the 
concerned point code is an ITU point code that doesn't 
have a route in the routing table. 


Verify a point code unavailable primitive is 
transmitted on the same socket the audit was 
received. 


FD-39 


Send from TALON a pomt code audit primitive where the 
concerned point code has a route in the routing table and 
there is a danger of circular routing as defined by existing 
SG rules. 


Verify a point code unavailable primitive is 
transmitted on the same socket the audit was 
received. 


FD-40 


Send from TALON a point code audit primitive where the 
concerned point code has a route in the routing table but 
the route is unavailable. 


Verify a point code unavailable primitive is 
transmitted on the same socket the audit was 
received. 


FD-41 


Send from TALON a point code audit primitive where the 
concerned point code has a route in the routing table and 
the route is available. 


Verify a point code available primitive is 
transmitted on the same socket the audit was 
received. 


FD-42 


Send from TALON a cluster audit primitives where the 
concerned point code doesn't have a route in the routing 
table and the cluster is unknown. 


Verify a cluster unavailable primitive is 
transmitted on the same socket the audit was 
received. 


FD-43 


Send from TALON a cluster audit primitives where the 
concerned point code doesn't have a route in the routing 
table and the cluster is known. 


Verify a cluster available primitive is 
transmitted on the same socket the audit was 
received. 


FD-44 


Send from TALON a cluster audit primitive where the 
concerned point code has a route in the routing table and 
there is a danger of circular routing as defined by existing 
SG rules. 


Verify a cluster unavailable primitive is 
transmitted on the same socket the audit was 
received. 


FD-45 


Send from TALON a cluster audit primitive where the 
concerned point code has a route in the routing table but 
the route is unavailable. 


Verify a cluster imavailable primitive is 
transmitted on the same socket the audit was 
received. 


FD-46 


Send from TALON a cluster audit primitive where the 
concerned point code has a route in the routing table and 
the route is available. 


Verify a cluster available primitive is 
transmitted on the same socket the audit was 
received. 


FD-47 


Send from TALON a cluster audit primitive where the 
concerned point code is the SG's true point code and is a 
member of a provisioned cluster. 


Verify a cluster available primitive is 
transmitted on the same socket the audit was 
received. 


FD-48 


Send from TALON a cluster audit primitive where the 
concerned point code is one of the SG's capability point 
codes and is a member of a provisioned cluster. 


Verify a cluster available primitive is 
transmitted on the same socket the audit was 
received. 



Table 6: FD Compliance Test Cases 
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4.3 Specification Compliance Testing 

Not applicable. 

4.4 Design Testing 

This section focuses on verifying the design requirements specified in Section 3 of the MTP Primitives DD [5] are 
implemented. 



Test# 



Command/Scenario 



Response/Result 



DT-1 



Send request for congestion status when the congestion 
audit history table is full and the last entry matches the 
requested concerned point code. 



Verify no RCT is generated and the primitive 
discard count is incremented. 



DT-2 



Send various UPU messages to a socket that has response 
method primitives enabled. 



Verify all valid fields (i.e. user id and cause 
code) can be generated. 



DT-3 



Verify response method replication algorithm by sending a 
message requiring replication which has the follow 
characteristics: 

1) no sockets with response method enabled 

2) no matching routing keys 

3) routing key matches for SI=0 only 

4) routing key matches for SI=3 only 

5) routing key matches for SI=5 only 

6) routing key matches for SI of 0 and 3 

7) routing key matches for SI of 0 and 5 

8) routing key matches for SI of 3 and 5 

9) routing key matches for SI of 0, 3 and 5 

1 0) no sockets available 



1) Verify primitive is discarded 

2) Verify primitive is discarded 

3) Verify primitive is sent to sockets 

4) Verify primitive is sent to sockets 

5) Verify primitive is sent to sockets 

6) Verify primitive is sent to sockets 

7) Verify primitive is sent to sockets 

8) Verify primitive is sent to sockets 

9) Verify primitive is sent to sockets 

1 0) Verify primitive is discarded 



DT-4 



Send SORP primitive with request for current flag 
settings. Change settings with SORP set command and 
reissue SORP request to verify set took effect. 



Verify valid reply messages are received 
with the expected values. 



DT-5 



Send multiple unique requests for congestion status. 



Verify SLS values are randomized. 



DT-6 



Send UPU with invalid user id destined for IP node. 



Verify user part unavailable primitive is 
generated with invalid user id. 



DT-7 



Send UPU with invalid cause code destined for IP node. 



Verify user part unavailable is generated 
with invalid cause code. 



DT-8 



Generate broadcast phase TFP message with no sockets 
configured with broadcast phase enabled. 



Verify TFP is not stored on MTPP work 
queue. 



DT-9 



Generate response method TFP message with no sockets 
configured with response method enabled. 



Verify TFP is not stored on MTPP work 
queue. 



DT-10 



Test that the normalized ISUP functionality works: 
1) Display the default setting for the normalized ISUP 
SORP flag using the SOCKSTATE PASS command 
Send an ISUP message to the TALON 
Enable the normalized ISUP SORP flag and verify 
setting using the SOCKSTATE PASS command 
Send an ISUP message to the TALON 
Disable the normalized ISUP SORP flag and verify 
setting using the SOCKSTATE PASS command 
Send an ISUP message to the TALON 



2) 
3) 

4) 
5) 



6) 



1) 

2) 



3) 
4) 



5) 
6) 



Verify Normalized ISUP is FALSE 
Verify TALON logs the message 
received as ISUP and sockstate log 
indicates ISUP message transmitted 
Verify Normalized ISUP is TRUE 
Verify TALON logs the message 
received as MTP3 and sockstate log 
indicates MTP3 message transmitted 
Verify Normalized ISUP is FALSE 
Verify TALON logs the message 
received as ISUP and sockstate log 
indicates ISUP message transmitted 
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Test# 


Command/Scenario 


Response/Result 


DT-11 


Test that the normahzed SCCP fimctionaHty works: 

1) Display the default setting for the normahzed SCCP 
SORP flag using the SOCKSTATE PASS command 

2) Send an SCCP message to the TALON 

3) Enable the normalized SCCP SORP flag and verify 
setting using the SOCKSTATE PASS command 

4) Send an SCCP message to the TALON 

5) Disable the normalized SCCP SORP flag and verify 
setting using the SOCKSTATE PASS command 

6) Send an SCCP message to the TALON 

7) Repeat for both Class 0 and Class SCCP messages 


1 ) Verify Normalized SCCP is FALSE 

2) Verify TALON logs the message 
received as SCCPP and sockstate log 
indicates SCCP message transmitted 

3) Verify Normalized SCCP is TRUE 

4) Verify TALON logs the message 
received as MTP3 and sockstate log 
indicates MTP3 message transmitted 

5) Verify Normalized SCCP is FALSE 

6) Verify TALON logs the message 
received as SCCP and sockstate log 
indicates SCCP message transmitted 

7) Both Class 0 and Class 1 should work. 



Table 7: Design Test Cases 
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4.5 Line of Code Testing 

The goal of this section is to verify the software design as specified in the DD. This is intended to answer the questions, "Can 
every possible line of code/decision path be executed?" and "Does every possible line of code/decision path generate the 
expected results?" The test cases below consist of the paths of code not tested by other test cases in this test plan. 



Test# 


Command/Scenario 


Response/Result 


LC-1 


When broadcast phase and response method counts are 
both non-zero, invoke sorp_get_mtp_counts function with 
invalid SORP MTPP option. 


Returned value is 0 


LC-2 


When broadcast phase and response method primitives are 
both enabled, invoke sorp_mtpp_enabled function with 
invalid SORP MTPP option. 


Returned value is false 


LC-3 


Force message on MTPP work queue with an invalid 
MTPP function id. 


Card boots. 


LC-4 


Send SNM message from MGTS to IP device via 
SS7IPGW that can't be decoded by DCD library. 


Card boots. 




Table 8: Line of Code Test Cases 


4.6 Performance Testing 

The goal of this section is to provide performance related testing for the MTP Primitives feature. 


Test# 


Command/Scenario 


Response/Result 


PT-1 


Measure time to generate RCT when congestion history is 
full and there are no matches to the requested DPC. 


Record time 


PT-2 


Measure time to generate RCT when congestion history is 
full and all entries are exceeding the time to live. 


Record time 


PT-3 


Measure performance of response method replication 
algorithm in worse case scenario that would include a full 
routing table with static and dynamic routing keys. Each 
routing key should the maximum number of sockets 
associated per routing key possible. 


Record time 



Table 9: Performance Test Cases 



4.7 Command Scripts 

Not applicable 

4.8 Load, Stress and Volume Testing 

This section focuses on testing that is designed to stress the transmit processing and in particular, the transmit scheduler. 



Test# 


Cominand/Scenario 


Response/Result 


LS-1 


Card level congestion testing 

1) transmit 1990 MSUs/sec & 1 broadcast phase 
primitive to be replicated to 10 sockets 

2) transmit 1991 MSUs/sec & 1 broadcast phase 
primitive to be replicated to 10 sockets 


1) card doesn't enter congestion 

2) card enter congestion after 
approximately 1000 seconds 


LS-2 


Run overnight duration run with bouncing SS7 links and 
IP traffic running. IP traffic should include MSUs as well 
as MTP Primitives because of the boimcing links 


Verify traffic can still be sent to IP node after 
overnight run. Verify no traffic was lost, no 
primitives discarded and all requests still 
being processed correctly. 



Table 10: Load, Stress and Volume Test Cases 
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4.9 PR Testing 

Not applicable 



4.10 Fault Insertion Testing 

This section focuses on verifying that the MTP Primitive feature handles faults. 



Test# 


Command/Scenario 


Response/Result 


FI-1 


Send primitive with MGMT opcode and invalid primitive 
operation from TALON. 


Verify primitive is discarded and neither 
MTPP nor SORP processmg is mvoked. 


FI-2 


Send SORP primitive with reply operation from IP node. 


Verify primitive is discarded. 


FI-3 


Send point code audit primitive from TALON with a 
cluster point code as the concerned point code. 


Verify primitive is discarded. 


FI-4 


Send cluster audit primitive from TALON with a full point 
code as the concerned point code. 


Verify primitive is discarded. 


FI-5 


Send point code audit primitive from TALON during frill 
restart. 


Verify primitive is discarded. 


FI-6 


Send cluster audit primitive from TALON during full 
restart. 


Verify primitive is discarded. 



Table 11: Fault Insertion Test Cases 



4.11 Sanity Testing 

Verify major feature(s) are present and functioning correctly in sanity. These tests reflect previous unit test cases that may be 
executed during the sanity phase of the build process. 



Test# 


Command/Scenario 


Response/Result 


ST-1 


Execute test case FD-1 


See FD-1 response 


ST-2 


Execute test case FD-2 


See FD-2 response ignoring socket counts 



Table 12: Sanity Test Cases 



4.12 Regression Testing 

This section provides a test case matrix that should be used to verify that the MTP Primitives feature is not negatively effecting 
an existing capability within the Eagle. 



Test# 


Command/Scenario 


Response/Result 


RT-1 


Send to LSL from MOTS a MSU with the concerned point 
code set to the SG's capability point code, the SI set to 3 
and SCCP unequipped. 


Verify TFP is transmitted to MGTS on same 
link MSU was received on. 


RT-2 


Send to LSL from MGTS a MSU with the concerned point 
code set to the SG's capability point code and the SI set to 

8. 


Verify TFP is transmitted to MGTS on same 
link MSU was received on. 


RT-3 


Send to LSL from MGTS a MSU with the concerned point 
code that has no route in the routing table. 


Verify TFP is transmitted to MGTS on same 
link MSU was received on. 


RT-4 


Send to LSL from MGTS a MSU with the concerned point 
code whose route in the routing table is inaccessible. 


Verify TFP is transmitted to MGTS on same 
link MSU was received on. 


RT^5 


Send to LSL from MGTS a MSU with the concerned point 
code set to the SG's capability point code, the SI set to 3, 
no SCCP service and MSU requires global title. 


Verify TFP is transmitted to MGTS on same 
link MSU was received on. 


RT-6 


Set up GWS such that MSUs and MTP Primitives are 
copied to SLAN card. 


Verify MSUs and MTP Primitives can be 
transmitted via SLAN interface. 



Table 13: Regression Test Cases 



4.1 3 Upgrade Testing 

Not applicable 
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5. TEST RESULTS 

5.1 Overall Test Summary 

The TOTAL row will calculate automatically when the document fields are updated. Update the cells with 
the formulas by selecting the entire contents of the document (Ctrl+A) and selecting the F9 command. 
Use the following to determine the Percentage Complete (% Comp) and Pass Rate: 

% Comp = (P+F)/(T-I) X 100 
Pass Rate = P/(P+F)x 100 





1 csi v^uicgory 


if Tpcfc 
ft 1 Colo 


Paccori 
fP) 


Failed 
(F) 


(B) 


Tnvnl iH 
li 1 veil lU 

(I) 


will VOlVU 

(U) 




Pass 
Rate 


1. 


FD Compliance Testing 


48 


34 


0 


0 


1 


13 


72% 


100% 


2. 


Specification Compliance Testing 


0 


0 


0 


0 


0 


0 


0% 


0% 


3. 


Design Testing 


11 


2 


0 


0 


0 


9 


18% 


100% 


4. 


Line of Code Testing 


4 


0 


0 


0 


0 


4 


0% 


!Zero 
Divide 


5. 


Performance Testing 


3 


0 


0 


0 


0 


3 


0% 


!Zero 
Divide 


6. 


Command Scripts 


0 


0 


0 


0 


0 


0 


0% 


0% 


7. 


Load/StressA^ olume 


2 


0 


0 


0 


0 


2 


0% 


!Zero 
Divide 


8. 


PR Testing 


0 


0 


0 


0 


0 


0 


0% 


0% 


9. 


Fault Insertion Testing 


6 


0 


0 


0 


0 


6 


0% 


!Zero 
Divide 


10. 


Regression Testing 


6 


5 


0 


0 


0 


1 


83% 


100% 


11. 


Upgrade Testing 


0 


0 


0 


0 


0 


0 


0% 


0% 




Total 


80 


41 


0 


0 


1 


38 


51.90 

% 


100% 



Table 14: Test Summary 



5.2 Detailed Results 

The purpose of this table is to document the results of each test case. An explanation of each column is 
included below. 

> Test # - Include ALL test numbers from section 4 of this document during the initial approval of the 
document. This is an autonumber field based on the test case category. 

> Status - Indicate the test results 

• P = Passed, F = Failed, B = Blocked, I = Invalid, U = Untested 

> Comments - Comments are required for all test cases where the Status column is something other 
than passed (P). A PR number is required for all Failed or Blocked test cases. 

> Date and Initials - Document the date the test was completed and enter the initials of the person 
completing the test. 

TABLES ARE INCLUDED FOR ALL TEST CATEGORIES FROM SECTION 4 OF THIS 
DOCUMENT. DELETE ANY SECTION THAT ARE NOT APPLICABLE AND ADD SECTIONS 
AS NECESSARY 
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1.1.1 5,2,1 FD Compliance Testing Results 



Test # 


Status 
(P, F, B. 1. U) 


Comments 


Date and 
initials 


FD-1 


Pass 




10/29/99 JWK 


FD-2 








FD-3 








FD-4 








FD-5 








FD-6 








FD-7 








FD-8 








FD-9 








FD-10 








FD-11 








FD-1 2 








FD-1 3 








FD-1 4 








FD-1 5 


Pass 




11/5/99 JWK 


FD-1 6 


Pass 




11/5/99 JWK 


FD-1 7 


Pass 




11/2/99 JWK 


FD-1 8 


Pass 




11/2/99 JWK 


FD-1 9 


Pass 




11/1/99 JWK 


FD-20 


Pass 




11/1/99 JWK 


FD-21 


Pass 




11/1/99 JWK 


FD-22 


Pass 




1 1/4/99 JWK 


FD-23 


Pass 




11/4/99 JWK 


FD-24 


Pass 




1 1/1/99 JWK 


FD-2 5 


Pass 




11/1/99 JWK 


FD-26 


Pass 




11/1/99 JWK 


FD-27 


Invalid 


Software only looks at the bits defined for the congestion level 
field so invalid bits are never seen. 




FD-28 


Pass 




11/4/99 JWK 


FD-29 


Pass 




11/4/99 JWK 


FD-30 


Pass 




11/4/99 JWK 


FD-31 


Pass 




11/4/99 JWK 


FD-32 


Pass 




11/5/99 JWK 


FD-33 


Pass 




11/1/99 JWK 


FD-34 


Pass 




11/1/99 JWK 


FD-35 


Pass 




11/1/99 JWK 


FD-36 


Pass 




11/1/99 JWK 


FD-37 


Pass 




11/1/99 JWK 


FD-3 8 


Pass 




11/1/99 JWK 


FD-39 


Pass 




11/1/99 JWK 


FD-40 


Pass 




11/1/99 JWK 


FD-41 


Pass 




11/1/99 JWK 


FD-42 


Pass 




11/5/99 JWK 


FD-43 


Pass 




11/5/99 JWK 


FD-44 


Pass 




11/5/99 JWK 


FD-45 


Pass 




1 1/5/99 JWK 


FD-46 


Pass 




11/5/99 JWK 


FD-47 


Pass 




11/5/99 JWK 
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Test# 


Status 
(P, F, B, 1, U) 


Comments 


Date and 
initials 


FD-48 


Pass 




11/5/99 JWK 



Table 15: FD Testing Detailed Results 



5.2.2 Design Testing 



1 esi ft 


oiaius 
(P. F, B, 1, U) 


^/^m in Ante 
w O in 111 c 1 1 L9 


UaW allU 

initials 


DT-1 








DT-2 








DT-3 








DT-4 








DT-5 








DT-6 








DT-7 








DT-8 








DT-9 








DT-10 


Pass 




11/6/99 JWK 


DT-11 


Pass 

Pass (step 7) 




1 1/6/99 JWK 
3/10/00 MED 



Table 16: Design Testing Detailed Results 



5.2.3 Line of Code Testing 



Test# 


Status 


Comments 


Date and 




(P. F, B, 1, U) 




initials 


LC-1 








LC-2 








LC-3 








LC-4 









Table 17: Line of Code Testing Detailed Results 



5.2.4 Performance Testing 



Test# 


status 


Comments 


Date and 




(P, F, B, 1, U) 




initials 


PT-1 








PT-2 








PT-3 









Table 18: Performance Testing Detailed Results 



5.2.5 Load, Stress and Volume Testing 



Test# 


status 
(P, F, B, 1, U) 


Comments 


Date and 
Initials 


LS-1 








LS-2 









Table 19: Load, Stress and Volume Testing Detailed Results 
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5.2.6 Fault Insertion Testing 



Test# 


Status 


Comments 


Date and 




(P, F, B, I, U) 




initials 


FI-1 








FI-2 








FI-3 








FI-4 








FI-5 








FI-6 









Table 20: Fault Insertion Testing Detailed Results 



5.2.7 Regression Testing 



Test# 


Status 


Comments 


Date and 




(P, F, B, 1, U) 




initials 


RT-1 


Pass 




1 1/6/99 JWK 


RT-2 


Pass 




1 1/5/99 JWK 


RT-3 


Pass 




11/6/99 JWK 


RT-4 


Pass 




11/6/99 JWK 


RT-5 


Pass 




1 1/6/99 JWK 


RT-6 









Table 21: Regression Testing Detailed Results 
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APPENDIX A PEER REVIEW CHECKLIST 

Do not delete this checklist. It shall be used at each peer review to ensure that all 
necessary attributes of the document are included. The moderator is responsible for 
asking these questions to the quorum prior to the document being voted on. 



The following table shall be used during the initial approval of the Unit Test Plan. 



Item 


Compliance 


Template is used and all sections are included (NA sections are so noted, not deleted). 




All applicable TEKELEC documents are cited 




The revision numbers in the header and footer match the number in the change history 




The correct quorum members according to the Peer Review procedure are present for the 
review of the document 




All applicable external/third party documents are cited 




All equipment required to perform the unit testing is identified and coordination has been 
accomplished to ensure that the equipment is available during the timeframes needed to 
perform the testing 




All requirements from the related FD documents are covered by test cases 




All applicable PFS requirements are covered by test cases 




The requirement matrix (section 3) includes all necessary FD and PFS requirements and 
has traceability to a Unit Test Case Number. 




All test case numbers are documented in the detailed results tables 




All code paths are tested 




All use cases are tested or risk assessed 




All applicable network or other system integration issues are covered or tested at the imit 
level 




Are any required simulators specified 




Table 22: Document Approval Checklist 
The following table shall be used after the test results are entered in this document. 


Item 


Compliance 


Test results are required for every test in section 4. 




The Test Summary table shall be complete and accurate. 




PRs shall be generated for all Failed and Blocked test cases and documented in the result 
tables in section 5. 




All untested test cases have a plan to have these test cases completed. 




Comments shall be entered in the result tables for all test cases except those that have 
passed. 




The level of compliance and amount of test coverage shall be documented in the 
requirement matrix in section 3. 





Table 23: Results Approval Checklist 
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APPENDIX B REVIEW SUMMARIES 

E-mail to "Meeting Minutes" and Project Team 



REVIEW MEETING SUMMARY REPORT 



Review: IP7 2.0 MTP Primitives Unit Test Plan 
Document: tp002911.doc 
Revision: 1.0 

Date: October 28, 1999 10AM - 12PM 
Author: Keller 
Review#: 1 
Moderator : Bo Hobbs 
Recorder : Joe Keller 



Reviewers: 
Name 

Mark Kanode 
Bo Hobbs 



Functional Area 
Software Dev 
Product Verification 



Review Time 
45 min 
20 min 



Score 

3 

3 



Not attending: 
Tricia Payne 
John Mason 
Don Hunnicutt 
Dan Brendes 
Raman Khadri 



Quality 

Marketing 

FOA 

Software Dev 
Software Dev 



delegated to Kanode 
no comments 
45 min 3 
no comments 
no comments 



Review conclusion by Moderator == 3 

(1) Unable to perform review 

(2) Unable to complete the review, another review required 

(3) Review completed, no more reviews required 

(4) Review completed pending changes, author will route for approval 

Average review preparation time : 36 minutes 



Actions & Issues 
None 

General Comments Actions 
1) None 

None 
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Specific Comments 

1) Fig 1 - stations 20201 and 20106 need to be labeled 
as such so that the traffic mix discussions are clear 



Actions 
Done 



2) 2.3.1 - 1st sentence should end in "verification and Done 
msg loss DETECTION can occur" 

3) Table 5 - FD-17 - verify this is covered in the TALI Done 
UTP 

4) Test Case FD-12 - What about combinations with Done 
SORP? Is 10% the right percentage for MTP? Thought 

it was 30%. Can you actually generate 2000 MTPP/sec 
with TALON to test #2 

5) Test Cases FD- 1 5 , 1 6, 1 7 - Results need to mention Done 
validation of ones that are processed normally 

(ie. valid requests) 

6) Test Case FD-27 - Is this really the way it works? Done 

7) Test Case DT-3 - Scenario #10 should say "no sockets Done 
available" 



8) Test Case DT-3 - Results #3-9, socket should be Done 
plural to verify replication 

9) Test Case LS-1 - where did 1000 seconds come from in Done 
the results? Are we overgranting in IPGW? If so, this 

would change your numbers. 



10) Test Case LS-2 - need to be running MTP and SORP Done 
requests along with MSU traffic. Should verify no 
traffic loss, no MTP/SORP discards, all requests 
still being processed correctly. 
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EXHIBIT B 

Greg Hunt 

From: "Khadri, Raman" <Raman.Khadri@tekelec.com> 

To: <ghunt@jwth.com> 

Sent: Friday, January 20, 2006 1 :18 PM 

Subject: FW: Status Report for 1 1/08/1999 - 1 1/12/1999 

Copy of the weekly status report 

Raman Khadri 

Tekelec - For What is Next 

raman.khadri(5)tekelec.com 

Desk : +1.919.380.3872 

Cell: +1.919.757.2997 

YIM : sr khadri 



From: Raman Khadri [mailto:raman.khadri(p)tekelec.com1 
Sent: Monday, November 15, 1999 8:50 AM 
To: Weekly Status Reports 
Cc: NSD DEVIP 

Subject: Status Report for 11/08/1999 - 11/12/1999 
Weekly Status Report for 11/08/1999 - 11/12/1999 

MILESTONES: ('*' indicates change from previous report) 



STATUS ORIGINAL FORECAST NEW Percentage TARGET Est.Person 
(RYGD) DATE DATE DATE Completed BUILD Days TASK 



Green 10/1 10/15 11/07 95% 1 IP7 2.0 MTP Primitives UT 

Green 50% 2 24/25 PR Merge Investigation 



TASK DESCRIPTION 



ACTIVITIES / ACCOMPLISHMENTS 



Primary : IP7 2.0 



Completed 36/37 Test cases of MTP Primitives Feature. One test case is blocked on the availability of 
Dynamic RTKEY feature. 



1/20/2006 
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Build 2.0.0-4-0-0 and 2.0.0-4-1-0 system releases. First one took one day to build and the second one 
took 0.5 days to build. 

Started investigation on 24/25 PRs that need to be merged with IP7 release. Created a initial list of all 
PRs that were fixed in 25.0 release till 250P01 release. There are 270+ PRs that were fixed. Started 
going thorugh each BCR for about 130 PRs so far and have reduced the number of PRs that need to be 
merged to about 120+ PRs. 

Spent about 2 hours reviewing MTP primitives FTP. 

Meetings : 



None 
PLANS 

1. Build 20.5.0.0 bulid 

2. Continue to work on 24/25 PR merge investigation. 

3. Test the blocked test cases of MTP primitive feature. 

ISSUES 



None at present 
PLANNED ABSENCES 



12-24-99 to 01-16-2000 

COMPLETED MILESTONES FOR 1Q99 



ORIGINAL ACTUAL 
DATE DATE TASK DESCRIPTION 



8/20 10/12 IP7 2.0 MTP Primitives FD/CS 
9/3 10/21 IP7 2.0 MTP Primitives DD 
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9/3 



10/22 IP7 2.0 MTP Primitives code 



June, July 



Several PR's 



5/23/99 UTP : Measurement mods 



3/19/99 5/7/99 UTP :Connectlon Manager 

3/26/99 5/7/99 UT : Connection Manager 

3/12/99 3/16/99 BCR : SS7IPGW base code 

2/12/99 3/10/99 UTP : TOS4V 

2/18/99 3/10/99 UT : TOS4V 

3/3/99 3/U/99 UTP : SS7IPGW base code 

3/11/99 3/11/99 UT : SS7IPGW base code 

1/27/99 Code:TOS4V 

1/26/99 Code : SS71PGW Base Code 

2/1/99 2/8/99 TOS4V and SS7IPGW HLD 



5/28/99 



UT : Measurement mods 



1/20/2006 



